Growth in the complexity new system-on-chip (SoC) ASICs and shortened project schedules responsive specific market windows are becoming more common trends in ASIC development. Designers currently resort to reuse of existing internal or commercial i.e., third party) IP design blocks as a way to reduce the design productivity gap. In doing so, a design-effort focus has shifted from block creation toward block integration at top-level register transfer level (RTL), synthesis environment, functional verification environment, and STA environment and layout levels.
Project time dedicated to integration and validation of an SoC STA environment is increasing in large part due to the fact that a reusability level of timing-verification-constraint code for IP design blocks is typically virtually zero in current systems. As opposed to the functional verification arena, where the concept of reusable verification IP (VIP) has evolved, reusability is a concept that is largely missing in the current timing-verification landscape.
STA code available from third-party IP design blocks cannot typically be used by an SoC integrator to build a chip-level timing analysis environment in a straightforward and efficient manner. Several issues in particular often hamper this effort:    1) Lack of standardization: Different IP providers follow a variety of formats and coding styles.    2) Limited scope of application: Timing specification embedded in the STA scripts restricts itself to the timing analysis of the IP design block in an isolated context.    3) Poor structure: The STA scripts follow an unstructured coding style where all timing constraints are contained in a single monolithic code block.    4) Incomplete constraining: Missing timing specifications delay the integration process due to additional support rounds required from the IP provider and, in a worst-case scenario, force the SoC integrator to reverse-engineer the design.    5) Inefficient maintenance: Updates in the IP design blocks often trigger a new constraint porting cycle, making maintenance of the SoC STA environment a cumbersome task.A typical scenario faced by an SoC STA integrator alternates between trying to port existing IP STA constraints by copy-paste and writing missing STA constraints following available IP timing documentation.
ASIC design and verification methodologies based on STA require specification of timing constraints as inputs to an STA analyzer tool. Electronic Design Automation (EDA) vendors develop a user interface of the STA analyzer using a high-level scripting language interpreter. On top of a built-in command set of the scripting language interpreter, EDA vendors develop special-purpose commands intended for timing constraints to be input to the analyzer. In turn, ASIC designers use the special-purpose commands to write scripts for performing STA analysis on hardware (i.e., ASIC) designs.
STA analysis scripts written for a specific hardware block or function constitute an item of a set of deliverables supplied by the IP vendor to a system-on-chip (SoC) integrator. The scope of the STA analysis scripts is typically limited to the isolated hardware block/function only. Therefore, the SoC integrator must adapt (e.g., by rewriting) the STA analysis scripts of the hardware block or function for the integrated SoC context.
Time spent by the SoC integrator building and validating the consistency of a chip-level timing analysis environment often negatively impacts an ASIC project schedule to a significant degree. An ASIC project schedule is fixed every time a new product development cycle starts. Typical ASIC project schedules are becoming shorter due to a common trend of resorting more to third-party IP hardware blocks or functions.